Webアプリケーション用の機能的なテストツールには多様なスタイルのものがあるが、その中でも最も模範的な違いは、Seleniumのように実際的な環境をフルに作るために一つかもしくはより多くのWebブラウザを動かすツールと、Canoo WebTestのようにWebブラウザが動作するやり方をシミュレートするツールがある。Marc Guillemot氏(source)はこの二つを比較し(source)、また彼の意見においてはWebTestが13対5の割合で勝利を勝ち取っている。
その二つを比較するにあたって、Marc氏はそれぞれのカテゴリーにおいてWebTestとSeleniumを勝者と考えている。
| Canoo WebTest | Selenium | 引き分け |
| Reports Speed Integration into Development Process Scalability Capture JS Errors Documentation Predictable Behaviour XPath Support Extensibility Data-Driven Tests Internationalization Support Support for Non-HTML Content |
Browser Fidelity Beginner Friendly Support for Badly Formatted HTML Code Multi-Language Support |
Testing Ajax |
Marc氏はテストが十分に速いことはないが、しかし”WebTestは単にやることが少なく、また全てはJVM内にて起こるのです。”と提案している。また彼はSelniumがテストを失敗に至らせるJavascriptのエラーを捕まえることができないと論じている。
あなたはユニットテストが通過する限り、プログラム内でのコンピレーションエラーを受け入れますか？とんでもないです！しかしながら、実のところまさにこれがあなたのアプリケーションに含まれているJavascriptのエラーが発見されない時に行うことなのです（それらが直接的にその特定のテストを失敗させるような影響を及ぼさない限り）。
彼はまた、一般的にブラウザシミュレーターの弱点であると考えられているAjaxのテストが重点に成り得ることを論じている。
人気をよそに、Ajaxの機能をテストするためにはブラウザ内でテストをJavaScriptとして動作させなくてもいいのです。HtmlUnitとそれゆえに、WebTestも同様にタスク次第なのです。またそれは予測できないビヘイビアを予測可能にし、ページ内のリクエストをどのようにスケジュールするかという点において、より良いコントロールを許容するので、それよりも優れているとさえも考えられるのです。参考に以前の私の掲載記事を参照してください。）。
一方、彼は複数の言語をサポートするSeleniumも称賛していて、”WebTestがAntに収束されている一方、Selenium RCは異なる言語（Java、Ruby、PHP等）にバインディングが可能である”と述べている。またそれが粗悪にフォーマットされたHTMLとブラウザの忠実度をサポートするという。
HtmlUnitのJavaScriptサポートは驚くべき進展を遂げましたが、未だ普通のブラウザのようには動作しません（そして今後も変わらないでしょう。）。Seleniumはアプリケーションの通常のJavaScript実行を修正しますが、それはブラウザそれ自体を使用し、それゆえにブラウザの標準のビヘイビアにより近いものなのです。
Canoo WebTestとHtmlUnitのリードデベロッパであるMarc氏は、明らかにこのスタイルのツールを好み認めていて、またこれに関して反論したい人は、まず彼の分析文書を読んで欲しいと述べている。
明確にすると、WebTest（とHtmlUnit) のコミッターとして、私は間違いなく偏った意見を持っています。一方私は数年間に渡って開発、保持されている巨大なテストスイートにおける経験もあります。客観的になろうとすると、過剰反応してSeleniumを過剰評価してしまうかもしれません。もちろん私がSeleniumに対して持っている意見に対して間違っているところがあれば、それは修正したいと思っています。でも批判する前に一度私の掲載記事を最後まで読んでみてください。
フィードバックにはいろいろな見解が含まれていた。またそれはWebTestとSeleniumが全く異なるものであるということを提示していた(source)。”Selenium、WebTest(HttpUnit)、 DBUnit、JUnitと他のものは補足的なものなのです。これでできてもそれで出来ないものがあるのが事実です。”他の人々は録画・プレイバック vs.スクリプトされたテストの優劣とテストの持続性(source)のためのアプローチに関して論議した。Murali氏はPragmatic QA Elementを提案した(source)。
Christian氏はWebTestのAjaxサポートに反論し(source)、彼のアプリケーションにおいて”HtmlUnitはDojoがステートメントをインポートするのを解析しないので一番シンプルなページでさえも例外を投げている”と主張している。
Simon氏(source)にとっては、ブラウザの忠実度が一番重要なポイントであった(source)。
WebTestのようなツールは多少理論的に思えます。それらはコードが完璧に働くことを証明するのですが、それはプロダクションに少し類似した理想的な環境においてのみ行われます。本物のユーザ達はIEやFirefox、Seleniumを使用していて、Seleniumはメモリ漏れする稚拙で、標準に準拠しないブラウザを用いて’現実的な’状況下でテストを行う事を可能にします。
WebTestが使用している、特定のエンジン上のアプリケーションを使用するクライアントなんて絶対にいないのです。それは、それが何かの上で稼働するということが分かっ て良いのですが、一方それがどうでもいいことであることを意味しているのです。その反対にSeleniumのテストはFirefox、IE上で動作し、また誰かがクロスプラットフォームに準拠しないで何かを記述した際に起こる問題をたくさん捕らえるのです。
最後に、Kent Tong氏は二つのアプローチを結びつかせている(source)。
WebTestとSelenium両方の上で動作できる、テスト一式の記述を可能にするミドルレイヤを開発することは可能なのでしょうか？このやり方でWebTestとSeleniumを毎晩頻繁に稼働させることによって、二つの世界を把握することができるでしょう。
あなたはこのどちらかを使用するだろうか。それとも他のテストツールを一緒に使用するだろうか？次世代のテストツールに関するディスカッションに参加したくなっただろうか？更なる情報に関してはCanoo WebTest(source)、Selenium(source)、Testing(source)と次世代のテストツールを読んで欲しい(source)。
原文はこちらです：http://www.infoq.com/news/2007/11/canoo-webtest-selenium-testing